The use of stale or dated data in various database systems can be problematic for certain users and for certain types of data. These problems can arise especially in time-sensitive applications involving information concerning pricing or availability. It is known that time-to-live, or TTL, caching systems provide limited solutions in certain circumstances for applications that may permit the use of data that is “slightly” stale, but these caching systems are not robust even in systems where even “slightly” stale data is permitted as the cached information will appear stale to an end user. Conveying even a “slightly” stale appearance can cause a loss of integrity with or confidence from the user.
Therefore, it is desirable to have the objects that are intended to be cached, such as information containing time-sensitive data (i.e., time, date, timestamp types of objects), remain up to date and not be displayed to the user in a “stale” format or mode.
For instance, when a Java application retrieves data from a date, time, and/or timestamp column, in a relational database (RDB) via Java Database Connectivity (JDBC) or Structured Query Language embedded in Java (SQLJ), a date, time, and/or timestamp Java object needs to be created for each value that is returned as part of the retrieval. Similarly, where Java applications retrieve data from date, time, timestamp columns in an RDB through a database driver, a Java object also needs to be created.
Unfortunately, the creation of Java objects (i.e., their instantiation), is time consuming and affects overall system performance particularly given a need to undertake numerous instantiation at any time. For example, a single Java object creation may require thousands of nanoseconds on a 200 MHz machine. Additionally, the date, time, timestamp constructor method requires extensive overhead resources to create and initialize underlying calendar and timezone structures in the objects, and it serializes on Time Zone methods, which prevent the scaling of applications processing in a high workload environments. Similarly, there is no database driver known to have successfully addressed these existing problems.
By example, in a web-based environment that may involve the web-sale of music compact discs (CDs), consumers visit a website and search for CDs of interest. As part of this search, consumers typically seek CD titles, associated pricing, and may ultimately make purchases of selected CDs. In providing the consumer with the web-information based on their search criteria, an application is called that will typically load general information about the CD (i.e., cover picture, item description, price, availability, comments, etc.) from the associated database. Once the general information is loaded, the application creates one or more objects (CD objects) to store the general information from one or more JDBC (Java Database Connectivity) result sets. After storing, the application may then render the CD objects as HTML and deliver the findings to the consumer's browser for display to the consumer. Typically, after the search findings are provided to the consumer, the application finalizes the consumer's request by allowing the Java Virtual Machine (JVM) to “garbage-collect” the created and complex CD objects for disposal. The JVM is typically a software “execution engine” in a browser, application or Oracle database that runs compiled java byte code (in class files). In operation, the above then occurs for each inquiry from each consumer even where the same search is conducted for a particular set of music characteristics (e.g., Rolling Stones CD). As a result, created objects are then churned and destroyed which is problematic for systems having moderate to high demand loads. Similarly, additional problems may results such as performance degradation if the CD objects are large and complex, thereby requiring multiple JDBC calls and often complex calculations.
FIG. 1 is a pictorial representation of the scenario in which there are n users conducting n searches. In the scenario 100, a database 110 stores resident information that may be searched on by numerous users (120, 130, 140 and 150) of the system. User 1, at 120, is a first requestor of information of the database 110 via a request for a search of information at 159. The application 160, which is common to all requestors in the scenario, has a low utilization based on the first request.
The utilization of the application is exemplified by a utilization box (155a, 155b, 155n) which is intended to be a depiction of real-time application utilization in view of user demands on the application. The utilization amount is indicated by a darkened region (161, 171, 181) within its associated utilization box in relation to the additional burden on the utilization of the application set forth by additional user requests.
The application 160, having received the first request 159 from user 120, searches for information at 162 within the database 110, and receives associated information on provided search characteristics at 163. The application 160 then loads the associated information received from 163. After loading the associated information, the application 160 creates objects (i.e., data objects) in view of the information sought and delivers the objects via 164 to the user 120. In performing this process, the application 160 has been utilized less than 100% of its capacity as is indicated by the partially shaded region of 161 of utilization box 155a. 
A second user 130, in the scenario, has a similar request of the same application 160 and undergoes a similar process of utilizing the application, searching the database, receiving associated information creating a data object and providing the data object created back to the user, as described previously. In concurrently or serially supporting multiple user requests, the application 160 is additionally burdened by the second user 130 request and demands for object creation, as is indicated by the larger utilization demands of the darkened area at 171 versus 161. The application 160 is utilized more at this stage of the scenario as is shown by the larger darkened area of 171, of utilization box 155b, versus the smaller darkened region of 161. This burden increases as demands on the application from additional users at 140 and additional complexity of requests rises. Users at 140 are those which are in addition to users at 120 and 130 but just prior to those who cause the application to reach maximum utilization at 150.
In the scenario, when an “nth” user 150 seeks to also perform a search request of the application 160 in accordance with a similar process previously described, the nth user is unable to have the application 160 accommodate the request due to the demands on the system from prior and concurrent users (120, 130, 140), as indicated by the darkened region at 181, of utilization box 155n, which indicates 100% utilization of the application. As a result, no object will be created for the user, at 190, as no search associated information searches have been received nor requested.
Accordingly, what is desired is a method to overcome the limitations of the present art and be able to create a value object for data that is requested a first time and then use that created value object for subsequent requests of similar data in associated result sets. The present invention addresses such a need.